Typical computer systems include a variety of constituent parts such as microprocessors, memories, peripheral devices, and device controllers. During the normal operation of such a computer system, utilization of some or all of these resources may be required for the successful completion of a given task. For example, in a single processor system running multiple programs, each executing program may simultaneously seek the use of the single processor resource. Alternatively, in multiprocessor systems, two or more of the processors may concurrently seek access to the same memory resource.
When simultaneous access to a shared resource is requested, errors are likely to occur. For example, incorrect data may be retrieved from a shared memory device or a shared processor may execute an incorrect sequence of instructions. To avoid such undesired consequences, serialization of these shared resources is necessary. Moreover, within such a serially reusable resource (SRR), certain operations performed thereupon require uninterrupted execution. These so-called atomic operations require means for permitting their unimpeded progression toward completion. For example, in operations involving queue pointer manipulation which are required for enqueueing or dequeueing of data, it is important to the integrity of the queue that the instructions proceed without interruption to their conclusion.
Typically, computer systems have provided serialized resource utilization via the implementation of shared resource locking techniques. Shared resource locks, which can be implemented via hardware or software, effectively disable the access of other devices to a shared resource while it is in use by a first device. For example, U.S. Pat. No. 4,574350 issued to Starr for Shared Resource Locking Apparatus, teaches a hardware-based locking unit which permits exclusive access to a shared resource via the issuance of a memory read command from the requesting device, and terminates the exclusive resource access via a memory write command therefrom. While such resource locking schemes are generally effective in serializing access to an SRR they do not address the need for providing atomic execution of certain operations.
Interrupt masking schemes have also been used to provide uninterrupted execution of operations. For example, the publication entitled Enterprise Systems Architecture/390 Principles of Operation, (pp. 6-2-6-6 Copyright International Business Machines Corporation, 1990, publication reference no. SA22-7201-00) generally describes a mechanism for enabling and disabling interrupt requests by setting mask bits in the currently executing program status word (PSW) and in the control registers of the central processing unit (CPU) (Enterprise Systems Architecture/390 is a trademark of International Business Machines Corporation). When a PSW mask bit is set to one for a particular type of interrupt, the interrupt request type is enabled, and these interruptions can occur (i.e. requests for these types of interrupts are granted access to the CPU). Alternatively, when a PSW mask bit is set to zero for a particular interrupt type, the interrupt request type is disabled, and the conditions causing these interruptions will generally remain pending (i.e. the requests are not forwarded to the CPU) thereby allowing an operation to continue through to its completion without these types of interruptions.
During the time interval for which interrupt requests are disabled, exceptions in the processing of an operation may occasionally cause the system to freeze. For example, such conditions may include a system deadlock due to unresolved contention for use of a shared resource. If the operation being performed while interrupt requests are disabled freezes, it follows that the system cannot regain control of the processor by means of an interrupt request, and consequently, the system cannot continue processing. Accordingly, there is requirement for a timer mechanism for re-enabling interrupt requests after a predetermined elapsed time. The elapsed time should be set so as to far exceed the normal time interval required for the completion of the operation being executed while the interrupt requests are disabled.
Such a timer mechanism, often described as a watchdog timer, is described in the Enterprise Systems Architecture/390 Principles of Operation, (pp. 6-11) which explains that the CPU timer measures elapsed CPU time and causes an interruption of the processing sequence when a specified amount of time has elapsed via an external interrupt request. The timer may be set to an initial value by executing the SET CPU TIMER instruction, a privileged instruction which is executed by the system and cannot be executed by a user. This precaution is typically implemented to assure the integrity of the system. If the value of the timeout counter were programmable by a user, that user could effectively permanently disable interrupt requests by setting a very high timer value, which would undermine the function of the computer system. Thus, a user seeking to disable interrupt requests and simultaneously initiate the watchdog timer cannot do so in a single instruction within this architecture. The SET CPU TIMER operation is not accessible to the user and as a result, the user wishing to disable interrupt requests for a period bounded by a watchdog timer is required to wait for the system execution of the set timer instruction, this implementation, while advantageous in ensuring system integrity, wastes valuable instruction cycles.
From the foregoing it can be seen that it would be useful to permit a user to programmably disable interrupt requests to assure the atomicity of a kernel of instructions and to simultaneously start a watchdog timer counting for a preestablished time period corresponding the duration of the user implemented disabling of interrupt requests, and wherein the preestablished time period is not accessible to the user. It is further desirable within such a system to provide programmable means for re-enabling the disabled interrupt requests within the predetermined time period and to provide a system level override which re-enables interrupt requests if the predetermined time period has expired without having the interrupt requests re-enabled by the user. With such a solution, a user would be permitted to mask interrupts for a controlled period of time. Advantageously, the user could use such a programmable interrupt mask to ensure atomicity of operations in a single processor system and enhance resource locking in multiprocessor systems.